现有 api 和hooks 总结

React 稳定版常用 API & Hooks 总表（不含实验特性）

基础 Hooks

性能优化 Hooks

DOM / 生命周期 Hooks

React DOM API

Hooks 使用规则（面试必考）

高频对比（面试非常常见）

一句话记忆（适合面试口语）

• useState：管理会影响 UI 的状态
• useRef：存不影响 UI 的值或拿 DOM
• useEffect：处理副作用
• useMemo：缓存结果
• useCallback：缓存函数
• useReducer：复杂状态机
• useContext：跨层传值
• useLayoutEffect：操作 DOM 时机更早

面试官最爱问的坑点

1. 为什么 useEffect 会执行两次？

因为 React StrictMode 开发模式故意检查副作用。

2. 为什么 setState 不立即更新？

因为批处理 + 调度机制。

3. 为什么不要滥用 useMemo/useCallback？

因为本身也有性能成本。

4. ref 为什么不触发更新？

因为它不是响应式状态。

最推荐你的记忆顺序（前端面试）

先背： useState → useEffect → useRef → useMemo → useCallback → useContext → useReducer

再背： forwardRef → useImperativeHandle → useTransition → useSyncExternalStore

对于大部分前端面试，这套已经覆盖 90%+ React 问题。

Q1: useState 和普通变量（例如 let count = 0）的核心区别是什么？为什么 React 不直接用普通变量管理 UI？

useState 和普通变量最核心的区别有两个：

1. 普通变量不会触发组件重新渲染

let count = 0;
count++;

即使值变了，React 并不知道这个变化，所以 UI 不会自动更新。

2. useState 会被 React 保存，并在更新时触发 rerender

xxxxxxxxxx
const [count, setCount] = useState(0);
setCount(count + 1);

调用 setCount 后：

• React 会更新 Fiber 中保存的状态
• React 会重新执行组件函数
• UI 会根据新状态重新渲染

3. 普通变量在函数组件重新执行时会被重置

xxxxxxxxxx
function Counter() {
  let count = 0;
}

每次 render 都重新从 0 开始。

而 useState 的值不会因为函数重新执行而丢失，因为 React 是按 Hook 链表（或索引）保存状态。

一句话总结: 普通变量只能存值；useState 不仅存值，还能通知 React 更新界面。

Standard Answer (English)

The core difference between useState and normal variables is:

1. Normal variables do not trigger re-render

xxxxxxxxxx
let count = 0;
count++;

Even if the value changes, React does not track it, so the UI will not update.

2. useState is tracked by React

xxxxxxxxxx
const [count, setCount] = useState(0);
setCount(count + 1);

When setCount is called:

• React stores the new state in Fiber
• React schedules a re-render
• The UI updates automatically

3. Normal variables reset on every render

Function components re-run entirely, so local variables are recreated.

useState persists because React stores it outside the function body.

面试官为什么问这个？

因为这是在考你是否真正理解：

• React 为什么是响应式
• Fiber 如何管理状态
• 为什么函数组件不是“执行一次”

实战场景

错误写法：

xxxxxxxxxx
let loading = false;
loading = true;

页面不会更新。

正确写法：

xxxxxxxxxx
const [loading, setLoading] = useState(false);
setLoading(true);

常见误区

错误：“useState 就是一个普通变量升级版”

正确：“useState 本质是 React 的状态调度系统的一部分”

面试口语版（中文）

useState 和普通变量最大的区别是，普通变量变化不会让 React 重新渲染，而且组件重新执行时变量会重置。useState 的状态是 React 保存的，调用 setter 后 React 会触发更新，所以 UI 能同步变化。

Interview Spoken Answer (English)

The biggest difference is that normal variables are not reactive. Changing them will not trigger a re-render, and they reset every time the component function runs again. useState is managed by React internally, so when we call the setter, React updates the state and re-renders the component automatically.

Q2: useEffect 的作用是什么？它和直接把代码写在组件函数体里面有什么本质区别？

问题：

例如：为什么下面这种写法通常有问题？

xxxxxxxxxx
function User() {
  fetch('/api/user');
  return <div>User</div>;
}

1. useEffect 的核心作用是：在 React 渲染完成后执行副作用代码，用于同步组件和 React 外部系统。

外部系统包括：

• API 请求
• DOM 操作
• 事件监听
• 定时器
• WebSocket
• localStorage

2. 为什么不能直接写在组件函数体里？

因为组件函数体的本质是： Render 阶段（渲染阶段）

React 要求 render 必须：

• 纯函数
• 无副作用
• 相同输入得到相同输出

错误示例：

xxxxxxxxxx
function User() {
  fetch('/api/user');
  return <div>User</div>;
}

这段代码的问题在于：每次组件重新渲染都会重新请求。

• state 更新
• props 更新
• 父组件更新

都会导致重复请求，甚至死循环。

正确写法：

xxxxxxxxxx
useEffect(() => {
  fetch('/api/user');
}, []);

This ensures the effect runs after render and only once on mount.

[] 的含义：只在首次挂载后执行一次。

本质区别

组件函数体：“描述 UI 应该长什么样”

useEffect：“UI 渲染后，需要顺便做什么事”

一句话总结：Render 用来计算界面，Effect 用来处理副作用。

Standard Answer (English)

1. useEffect is used to run side effects after React finishes rendering.

Examples:

• Fetching data
• Event listeners
• Timers
• DOM subscriptions
• External APIs

2. Why not put side effects directly inside the component body?

Because the component body runs during the render phase, which should stay pure.

React may re-run the component many times, so this:

xxxxxxxxxx
fetch('/api/user');

could trigger repeated requests on every render.

面试官为什么问这个？

因为这题在考：

• 你是否理解 render 是纯函数
• 你是否知道副作用执行时机
• 你是否理解 React 生命周期思维

实战场景

常见错误：

xxxxxxxxxx
setInterval(...)
window.addEventListener(...)
fetch(...)

直接写组件里，可能造成：

• 重复绑定
• 内存泄漏
• 无限请求

常见误区

错误：“useEffect = componentDidMount”

正确：useEffect 更像 “render 后同步副作用”，不仅仅是 mount。

面试口语版（中文）

useEffect 主要用于处理副作用，比如请求接口、事件监听或者定时器。因为组件函数本身是 render 阶段，应该保持纯净，如果直接把 fetch 写在函数体里，每次重新渲染都会执行，容易造成重复请求。useEffect 可以让这些操作在渲染完成后按依赖控制执行。

Interview Spoken Answer (English)

useEffect is mainly used for side effects like API calls, event listeners, or timers. The component body itself is the render phase and should stay pure. If we put something like fetch directly inside it, it may run on every render and cause repeated requests. useEffect lets us run those side effects after rendering and control them with dependencies.

Q3: useEffect 的依赖数组（dependency array）到底是做什么的？

请你分别解释下面三种情况的区别，以及实际开发中各自适合什么场景：

xxxxxxxxxx
useEffect(() => {});
useEffect(() => {}, []);
useEffect(() => {}, [count]);

useEffect 的第二个参数（依赖数组）本质上是： 告诉 React，当哪些依赖变化时，需要重新执行这个副作用。

React 会用浅比较（Object.is）检查依赖是否变化。

第一种：

xxxxxxxxxx
useEffect(() => {});

含义：没有依赖数组 → 每次 render 后都执行

执行时机：

• 首次渲染后执行
• 每次 state / props 更新后都执行

场景：很少用，因为容易造成性能问题。

风险：如果里面 setState，容易无限循环。

第二种：

xxxxxxxxxx
useEffect(() => {}, []);

含义：空依赖 → 只在首次挂载后执行一次

场景：

• 初始化请求
• 注册事件监听
• 启动定时器

注意：

如果引用外部变量，但不加依赖，可能拿到旧值（stale closure）。

第三种：

xxxxxxxxxx
useEffect(() => {}, [count]);

含义：首次执行 + count 改变时重新执行

场景：

• 根据搜索词重新请求
• 根据 id 获取详情
• 状态变化同步外部系统

示例：

xxxxxxxxxx
useEffect(() => {
  fetchUser(count);
}, [count]);

一句话总结

• 不写依赖数组：每次 render 后都执行
• []：只执行一次
• [x]：首次 + x 改变时执行

更底层理解

不是“执行次数控制器”，而是：副作用和依赖之间的同步声明。

Standard Answer (English)

The dependency array tells React when the effect needs to re-run based on specific reactive values.

1.

xxxxxxxxxx
useEffect(() => {});

Runs after every render.

Use case:

Rarely useful, can cause performance issues.

2.

xxxxxxxxxx
useEffect(() => {}, []);

Runs only once after initial mount.

Use case:

• Initial fetch
• Event listeners
• Setup logic

3.

xxxxxxxxxx
useEffect(() => {}, [count]);

Runs on mount + whenever count changes.

Use case:

Syncing side effects with changing state.

面试官为什么问这个？

因为这题核心在考：

• 你是否理解 React dependency model
• 是否知道 stale closure
• 是否理解无限循环根源

实战场景

搜索：

xxxxxxxxxx
useEffect(() => {
  search(keyword);
}, [keyword]);

监听：

xxxxxxxxxx
useEffect(() => {
  window.addEventListener(...);
  return () => window.removeEventListener(...);
}, []);

常见误区

错误：“[] 就等于 componentDidMount”

正确：更像“首次同步”，不是类组件生命周期的简单复制。

错误：“依赖不写更省事”

正确：

如果不写依赖可能导致：

• 无限执行
• 数据不同步
• 闭包旧值

面试口语版（中文）

依赖数组本质上是告诉 React，这个 effect 依赖哪些值变化。不写依赖就是每次渲染后都执行；空数组表示只在首次挂载执行一次；而写 [count] 表示首次挂载时执行，并且 count 改变时重新执行。实际开发里最重要的是保证副作用和依赖同步，否则容易出现无限循环或者拿到旧数据。

Interview Spoken Answer (English)

The dependency array tells React which values this effect depends on. Without it, the effect runs after every render. With an empty array, it runs only once after mount. With [count], it runs on mount and whenever count changes. In real projects, it’s mainly about keeping side effects synchronized with state changes and avoiding stale data or infinite loops.

Q4: 为什么 useEffect 里有时候需要返回一个 cleanup function（清理函数）？

请你结合真实开发场景解释：如果不清理，可能会出现什么问题？

例如：

xxxxxxxxxx
useEffect(() => {
  window.addEventListener('resize', handleResize);
}, []);

useEffect 返回 cleanup function 的核心作用是： 在副作用失效前，撤销之前注册的外部资源，避免重复订阅、资源残留和状态错误。

常见需要清理的场景

1. 事件监听

xxxxxxxxxx
useEffect(() => {
  window.addEventListener('resize', handleResize);
​
  return () => {
    window.removeEventListener('resize', handleResize);
  };
}, []);

为什么必须清理？

如果组件卸载后不移除：

• 监听器仍然存在
• 回调继续执行
• 引用组件旧状态
• 可能重复绑定多个监听器

结果可能包括：

• 内存泄漏

  无用引用无法被 GC 回收

• 重复执行

  一个 resize 触发多次 callback

• 状态更新到已卸载组件

  可能出现：“Can't perform a React state update on an unmounted component”

2. 定时器

xxxxxxxxxx
useEffect(() => {
  const timer = setInterval(...);
​
  return () => clearInterval(timer);
}, []);

3. WebSocket / Subscription

xxxxxxxxxx
return () => socket.close();

4. Abort fetch

xxxxxxxxxx
return () => controller.abort();

执行时机

Cleanup 会在两种情况下执行：

• 组件卸载时

• 下一次 effect 执行前（依赖变化）

  示例：

  ​x
  useEffect(() => {
    subscribe(id);
  ​
    return () => unsubscribe(id);
  }, [id]);
  

  当 id 改变时：先取消旧订阅，再创建新订阅。

一句话总结：cleanup 的本质不是“清理代码”，而是撤销上一次副作用。

Standard Answer (English)

The cleanup function is used to remove or cancel side effects before they become invalid.

Its purpose is to:

• Prevent memory leaks
• Avoid duplicate subscriptions
• Stop stale async logic
• Prevent updates after unmount

Example:

xxxxxxxxxx
useEffect(() => {
  window.addEventListener('resize', handleResize);
​
  return () => {
    window.removeEventListener('resize', handleResize);
  };
}, []);

Without cleanup:

• Event listeners stay active
• Multiple listeners may stack
• Old closures may persist
• Memory/resources are wasted

Cleanup runs when:

1. Component unmounts
2. Before effect re-runs

面试官为什么问这个？

因为这是在考：

• 你是否理解副作用生命周期
• 是否能避免 memory leak
• 是否真正做过真实项目

实战场景（非常常见）

错误：

xxxxxxxxxx
useEffect(() => {
  setInterval(() => {
    console.log('tick');
  }, 1000);
}, []);

组件卸载后 interval 还在跑。

正确的写法，需要加上清理函数：

xxxxxxxxxx
return () => clearInterval(timer);

常见误区

错误：“只有卸载时才 cleanup”

正确：依赖变化时也会 cleanup 上一次 effect。

错误：“fetch 不需要 cleanup”

正确：异步请求也可能需要 abort，避免竞态问题。

面试口语版（中文）

cleanup function 的作用是撤销上一次副作用，比如移除事件监听、清除定时器、关闭订阅。如果不清理，组件卸载后这些外部资源可能还继续运行，导致内存泄漏、重复执行，甚至更新已经卸载的组件。它本质上是保证副作用生命周期正确。

Interview Spoken Answer (English)

The cleanup function is used to undo previous side effects, such as removing event listeners, clearing timers, or unsubscribing from external resources. Without cleanup, those side effects may continue after the component unmounts, causing memory leaks, duplicate execution, or stale state updates. Its main purpose is to keep side effects properly synchronized with the component lifecycle.

Q27: useEffect的执行流程是什么？什么会触发useEffect重新执行？组件重新渲染会触发useEffect重新执行吗？

useEffect 并不是发生在 Render 阶段，而是在 Commit 阶段完成 DOM 更新以后 才执行。

整个执行流程如下：

xxxxxxxxxx
State 更新
      │
      ▼
Render Phase（计算新的 Virtual DOM）
      │
      ▼
Diff（找出变化）
      │
      ▼
Commit Phase（更新真实 DOM）
      │
      ▼
浏览器 Paint（页面显示）
      │
      ▼
React 执行 useEffect

所以：

useEffect 永远不会阻塞页面渲染。

页面已经更新完成之后，React 才会去执行 Effect。

React 是什么时候决定要不要执行 Effect？

React 在 Render 阶段就已经决定好了。

例如：

xxxxxxxxxx
useEffect(() => {
  console.log("effect");
}, [count]);

Render 的时候，React 会做两件事情：

xxxxxxxxxx
上一次依赖
​
[count = 1]
​
当前依赖
​
[count = 2]

然后使用

Object.is(oldValue, newValue)

逐个比较 dependency。

React 内部类似：

xxxxxxxxxx
shouldRun = false;
​
for (let i = 0; i < deps.length; i++) {
    if (!Object.is(oldDeps[i], newDeps[i])) {
        shouldRun = true;
        break;
    }
}

如果发现有任何一个依赖变化：

xxxxxxxxxx
shouldRun = true

React 就会给当前 Fiber 打上一个 Effect 标记（effect flag）。

真正执行则发生在 Commit 之后。

什么情况下会重新执行 useEffect？

很多人会回答：

状态变化。

其实更准确一点应该说：

组件发生一次新的 Render，并且依赖发生变化。

因为：

useEffect 从来不是"状态变化触发"，而是 Render 完成以后根据 dependency 判断是否执行。

例如：

xxxxxxxxxx
const [count, setCount] = useState(0);
​
useEffect(() => {
    console.log("effect");
}, [count]);

执行

xxxxxxxxxx
setCount(1);

流程：

xxxxxxxxxx
setCount
​
↓
​
组件重新 Render
​
↓
​
比较 deps
​
↓
​
count 变化
​
↓
​
Commit
​
↓
​
执行 effect

真正触发 Effect 的不是 setState。

而是：

xxxxxxxxxx
新的 Render
+
dependency 变化

那组件重新 Render，会不会执行 useEffect？

答案：

不一定。

这是很多人容易答错的地方。

例如：

xxxxxxxxxx
function App() {
    const [count, setCount] = useState(0);
    const [name, setName] = useState("");
​
    useEffect(() => {
        console.log("effect");
    }, [count]);
​
    ...
}

点击：

xxxxxxxxxx
setName("Tom");

会发生：

xxxxxxxxxx
重新 Render

因为 state 更新了。

但是：

xxxxxxxxxx
旧 deps
​
[count = 0]
​
新 deps
​
[count = 0]

React 比较以后：

xxxxxxxxxx
Object.is(0, 0)
​
true

于是：

xxxxxxxxxx
不执行 effect

所以：

组件重新 Render ≠ useEffect 一定重新执行。

必须依赖发生变化。

如果没有 dependency 呢？

例如：

xxxxxxxxxx
useEffect(() => {
    console.log("effect");
});

没有第二个参数。

React 会认为：

xxxxxxxxxx
每次 Render
↓
​
都需要执行

所以：

xxxxxxxxxx
Render
​
↓
​
Commit
​
↓
​
Effect

每一次都会执行。

例如：

xxxxxxxxxx
setCount()

↓

xxxxxxxxxx
Render
​
↓
​
effect

再：

xxxxxxxxxx
setName()

↓

xxxxxxxxxx
Render
​
↓
​
effect

都会执行。

空数组呢？

xxxxxxxxxx
useEffect(() => {
    console.log("effect");
}, []);

第一次：

xxxxxxxxxx
mount
​
↓
​
Render
​
↓
​
Commit
​
↓
​
effect

以后：

xxxxxxxxxx
重新 Render
​
↓
​
deps 为空
​
↓
​
没有变化
​
↓
​
不会再次执行

所以：

xxxxxxxxxx
[]

表示：

只在组件挂载完成后的首次 Commit 后执行一次（开发模式下开启 Strict Mode 时会额外执行一次用于检查副作用）。

Dependency 是对象呢？

例如：

xxxxxxxxxx
useEffect(() => {
    console.log("effect");
}, [user]);

React 比较的是：

xxxxxxxxxx
Object.is(oldUser, newUser)

比较的是引用。

例如：

xxxxxxxxxx
setUser({
    name: "Tom"
});

虽然内容一样：

xxxxxxxxxx
{
   name: "Tom"
}

但是：

xxxxxxxxxx
old !== new

因此：

xxxxxxxxxx
effect 会重新执行

Cleanup 什么时候执行？

例如：

xxxxxxxxxx
useEffect(() => {
    console.log("mount");
​
    return () => {
        console.log("cleanup");
    };
}, [count]);

执行流程：

第一次：

xxxxxxxxxx
Render
​
↓
​
Commit
​
↓
​
effect

第二次：

xxxxxxxxxx
Render
​
↓
​
deps 改变
​
↓
​
Commit
​
↓
​
cleanup（旧 effect）
​
↓
​
effect（新 effect）

可以记住一句话：

React 总是先清理上一次 Effect，再执行下一次 Effect。

组件卸载时：

xxxxxxxxxx
Unmount
​
↓
​
cleanup

也会执行一次清理函数。

完整生命周期流程

xxxxxxxxxx
第一次挂载（Mount）
​
Render
    │
    ▼
比较 deps（第一次一定执行）
    │
    ▼
Commit（更新 DOM）
    │
    ▼
浏览器绘制（Paint）
    │
    ▼
执行 useEffect
更新（依赖变化）
​
setState / props 变化
        │
        ▼
Render
        │
        ▼
比较 deps
        │
        ▼
依赖变化？
      /      \
    否        是
    │          │
    │       Commit
    │          │
    │          ▼
    │     cleanup（旧 effect）
    │          │
    │          ▼
    └──────► 执行新的 effect

英文面试回答

useEffect runs after the component has been committed to the DOM. During the render phase, React compares the current dependency array with the previous one using Object.is(). If any dependency has changed, React marks the effect to run. After the commit phase, React first runs the cleanup function from the previous effect (if there is one), and then executes the new effect.

A component re-render alone does not guarantee that useEffect will run. The component must re-render, and at least one dependency must have changed. If the dependency array is omitted, the effect runs after every render. If it's an empty array ([]), it only runs after the initial mount (except for the extra development-only execution in Strict Mode).

面试官最喜欢追问的一句话

很多候选人会说：

"state 变化会触发 useEffect。"

更准确的回答应该是：

State 或 props 的变化会导致组件重新渲染（Render）。在 Render 阶段，React 会比较依赖数组；只有依赖发生变化，React 才会在 Commit 完成后执行 useEffect。因此，组件重新渲染只是必要条件，而不是充分条件。

Q28: 事件绑定到底是写成{handleClick}还是{() => handleClick()}？

这是 React 面试里非常常见的问题。答案不是简单地说哪个对，而是要看你想传递什么。

1. 推荐默认写法：{handleClick}

例如：

xxxxxxxxxx
function Button() {
  const handleClick = () => {
    console.log("clicked");
  };
​
  return (
    <button onClick={handleClick}>
      Click
    </button>
  );
}

这里传递的是：

xxxxxxxxxx
handleClick

这个函数本身的引用。

React 内部会在点击时调用：

xxxxxxxxxx
handleClick(event)

所以等价于：

xxxxxxxxxx
<button onClick={(event) => handleClick(event)}>

执行流程

xxxxxxxxxx
组件 Render
​
↓
​
创建 handleClick 函数
​
↓
​
把函数引用传给 onClick
​
↓
​
用户点击
​
↓
​
React 调用 handleClick(event)

2. {() => handleClick()} 也可以，但它创建了一个新函数

例如：

xxxxxxxxxx
<button onClick={() => handleClick()}>
  Click
</button>

这里传递给 React 的不是 handleClick。

而是：

xxxxxxxxxx
() => handleClick()

一个新的匿名函数。

每次 Render：

xxxxxxxxxx
Render 1
​
() => handleClick()
     ↑
     新函数
​
​
Render 2
​
() => handleClick()
     ↑
     又是一个新函数

所以引用不同：

xxxxxxxxxx
oldFunction !== newFunction

3. 那什么时候必须用箭头函数？

当你需要传参数的时候。

例如：

xxxxxxxxxx
function UserList() {
​
  const deleteUser = (id: number) => {
    console.log(id);
  };
​
  return (
    <button onClick={() => deleteUser(123)}>
      Delete
    </button>
  );
}

如果直接写：

xxxxxxxxxx
<button onClick={deleteUser(123)}>

错误。

因为：

xxxxxxxxxx
deleteUser(123)

会立即执行。

Render 时：

xxxxxxxxxx
组件渲染
​
↓
​
执行 deleteUser(123)
​
↓
​
把返回值传给 onClick

但是 React 需要的是：

xxxxxxxxxx
function

而不是执行结果。

4. 一个常见错误

❌ 错误：

xxxxxxxxxx
<button onClick={handleClick()}>

因为：

Render 阶段：

xxxxxxxxxx
Render
​
↓
​
执行 handleClick()
​
↓
​
返回 undefined
​
↓
​
onClick={undefined}

点击按钮时：

xxxxxxxxxx
没有函数可以执行

5. 性能区别（面试重点）

假设：

xxxxxxxxxx
function App(){
​
 const handleClick = () => {
   console.log("click");
 }
​
 return (
   <Button onClick={handleClick}/>
 )
​
}

和：

xxxxxxxxxx
function App(){
​
 const handleClick = () => {
   console.log("click");
 }
​
 return (
   <Button 
      onClick={() => handleClick()}
   />
 )
​
}

区别：

第一种：

xxxxxxxxxx
每次 Render:
​
handleClick
      ↓
同一个引用（如果 useCallback）

第二种：

xxxxxxxxxx
每次 Render:
​
创建新的匿名函数
      ↓
引用变化

如果子组件：

xxxxxxxxxx
const Button = React.memo(({onClick})=>{
   ...
})

第二种可能导致：

xxxxxxxxxx
props变化
​
↓
​
React.memo失效
​
↓
​
Button重新渲染

6. 那是不是永远不要写箭头函数？

不是。

实际开发：

简单事件

推荐：

xxxxxxxxxx
<button onClick={handleClick}>

需要传参数

使用：

xxxxxxxxxx
<button onClick={() => deleteUser(id)}>

列表场景

例如：

xxxxxxxxxx
users.map(user => (
  <button
    key={user.id}
    onClick={() => deleteUser(user.id)}
  >
    Delete
  </button>
))

这是正常写法。

7. 面试标准回答（英文）

In React, we usually pass the function reference directly, like onClick={handleClick}. React will call this function automatically and pass the event object as the argument.

We use an arrow function like onClick={() => handleClick(id)} when we need to pass additional parameters or execute custom logic before calling the handler.

The difference is that the arrow function creates a new function on every render, which may cause unnecessary re-renders for memoized child components.

一句话记忆：

面试时回答：

"Use onClick={handleClick} by default. Use onClick={() => handleClick(id)} only when you need to pass arguments or add extra logic."

Q5: useRef 和 useState 都可以“保存值”，那它们的本质区别是什么？

请你结合真实开发场景回答：

1. 什么情况下你会用 useRef 而不是 useState？
2. 为什么修改 ref.current 不会触发重新渲染？
3. useRef 除了操作 DOM，还有哪些常见用途？

useRef 和 useState 都能跨 render 保存值，但本质区别是：

1. 核心区别

useState用于影响 UI 的响应式状态

xxxxxxxxxx
const [count, setCount] = useState(0);

特点：

• 更新会触发 rerender
• React 会重新渲染组件
• 适合界面展示数据

useRef

用于保存不会影响 UI 的可变值

xxxxxxxxxx
const countRef = useRef(0);
countRef.current++;

特点：

• 修改 .current 不会 rerender
• 生命周期贯穿整个组件
• React 不追踪它的变化

为什么 ref.current 不触发更新？

因为 React 的更新机制只监听：

• state
• props
• context

ref 本质更像：一个持久化的普通对象容器

xxxxxxxxxx
{ current: value }

改它不会进入 React 调度流程。

useRef的实战场景

场景1：操作 DOM

xxxxxxxxxx
inputRef.current.focus();

场景2：保存定时器 ID

xxxxxxxxxx
const timerRef = useRef(null);

避免 rerender。

场景3：保存上一次值

xxxxxxxxxx
prevValueRef.current = value;

场景4：避免 stale closure

保存最新 callback。

什么时候选 useRef 而不是 useState？

用 useRef：

• DOM
• timer id
• websocket instance
• previous value
• mutable cache

用 useState：

• count
• loading
• modal open
• form data
• 任何需要更新 UI 的数据

一句话总结useState 管 UI，useRef 管引用。

Standard Answer (English)

Both useState and useRef persist values across renders, but:

useState

Used for reactive state that affects UI.

• Updating it triggers re-render
• React tracks changes

useRef

Used for mutable values that should persist but not trigger UI updates.

• Updating ref.current does not re-render
• React does not track it

Why?

Because useRef is just a persistent object:

xxxxxxxxxx
{ current: ... }

React doesn’t schedule updates for it.

useRef common real-world uses:

DOM access

Timer IDs

Previous values

External instances

Avoiding stale closures

面试官为什么问这个？

因为这题考你：

• 是否理解 React 响应式机制
• 是否会避免不必要 rerender
• 是否真正写过性能优化代码

常见误区

错误：“useRef 就是拿 DOM 的”

正确：DOM 只是其中一个用途，它更常用于持久化非 UI 数据。

错误：“useRef 不能改”

正确：可以改，但 React 不关心。

面试口语版（中文）

useState 和 useRef 都可以跨渲染保存值，但 useState 是响应式状态，更新后会触发组件重新渲染，适合管理 UI。useRef 更像一个持久化容器，修改 .current 不会触发渲染，所以更适合保存 DOM、定时器、上一次值或者其他不影响界面的数据。

Interview Spoken Answer (English)

Both useState and useRef can persist values across renders, but useState is reactive and triggers re-render when updated, so it’s used for UI state. useRef is more like a persistent container whose .current value can change without causing re-render, so it’s useful for DOM references, timers, previous values, or other mutable data that doesn’t directly affect the UI.

Q6: useMemo 和 useCallback 的区别是什么？它们分别解决什么问题？

请你结合实际开发说明：

1. 它们各自缓存的是什么？
2. 为什么 React 需要它们？
3. 什么时候“用了反而更慢”？

一、核心区别（一句话）

• useMemo：缓存计算结果（值）
• useCallback：缓存函数本身

1. 它们分别缓存什么？

useMemo：缓存“值”

xxxxxxxxxx
const result = useMemo(() => {
  return computeExpensiveValue(count);
}, [count]);

👉 返回的是“计算后的结果”

useCallback：缓存“函数”

xxxxxxxxxx
const handleClick = useCallback(() => {
  console.log(count);
}, [count]);

👉 返回的是“函数引用本身”

2. 本质关系（重点）

👉 useCallback 其实是 useMemo 的语法糖

xxxxxxxxxx
useCallback(fn, deps)
// 等价于
useMemo(() => fn, deps)

3. 为什么 React 需要它们？

React 默认行为：

每次 render：

• 函数都会重新创建
• 计算都会重新执行

问题1：昂贵计算重复执行

xxxxxxxxxx
const value = heavyCompute(data);

👉 每次 render 都算一次（浪费性能）

问题2：子组件不必要 rerender

xxxxxxxxxx
<Child onClick={() => doSomething()} />

👉 每次 render 都生成新函数 👉 子组件即使 memo 也会重新渲染

4. useMemo / useCallback 解决什么问题？

5. 什么时候“用了反而更慢”？

这是面试重点（很多人答不出来）

❌ 情况1：计算很简单

xxxxxxxxxx
const sum = useMemo(() => a + b, [a, b]);

👉 useMemo 本身有缓存开销 👉 比直接计算更慢

❌ 情况2：子组件没优化

xxxxxxxxxx
const handle = useCallback(() => {}, []);

但 Child 没有 memo：

👉 用不用 useCallback 都一样 rerender

❌ 情况3：依赖变化频繁

如果 deps 每次都变：等于“白缓存”

6. 正确使用场景

useMemo

• 大计算（filter / sort / transform）
• 避免重复计算
• 渲染列表优化

useCallback

• 传给 memo 子组件
• event handler
• 防止 props 引用变化

一句话总结

👉 useMemo 优化“计算” 👉 useCallback 优化“函数引用”

Standard Answer (English)

Core difference:

• useMemo caches a computed value
• useCallback caches a function

1. What they cache

useMemo:

xxxxxxxxxx
const value = useMemo(() => compute(), [deps]);

Returns a memoized value.

useCallback:

xxxxxxxxxx
const fn = useCallback(() => {}, [deps]);

Returns a memoized function reference.

2. Why React needs them

Because by default:

• Functions are recreated every render
• Expensive computations run again

3. When they can hurt performance

• Computation is cheap → overhead > benefit
• Child component is not memoized
• Dependencies change too often → no real caching benefit

面试口语版（中文）

useMemo 是用来缓存计算结果的，避免每次 render 都做重复计算，比如排序或者过滤列表。useCallback 是用来缓存函数本身，避免函数引用变化导致子组件不必要的重新渲染。两者本质区别是一个缓存值，一个缓存函数。但如果计算很简单或者子组件没有做 memo 优化，用它们反而可能增加性能开销。

Interview Spoken Answer (English)

useMemo is used to memoize computed values to avoid expensive recalculations on every render. useCallback is used to memoize function references so that child components don’t re-render unnecessarily due to changed props. However, if the computation is trivial(琐碎的，不重要的) or the child component is not optimized with memo, using them can actually hurt performance instead of improving it.

Q7: useEffect 依赖项里如果写错了，会出现什么问题？

请结合实际开发回答：

1. 依赖写少了会怎样？
2. 依赖写多了会怎样？
3. 为什么 React 不帮你自动处理依赖？

一、依赖写少了会怎样？

👉 会出现“数据过期 / 闭包旧值问题（stale closure）”

例子：

xxxxxxxxxx
useEffect(() => {
  console.log(count);
}, []);

问题：

• effect 只执行一次
• 里面的 count 永远是“初始值”
• 后续更新不会感知

结果：

👉 UI 和逻辑不同步 👉 使用旧数据

二、依赖写多了会怎样？

👉 effect 频繁执行，引发性能问题甚至死循环

例子：

xxxxxxxxxx
useEffect(() => {
  fetchData();
}, [data]);

问题：

• effect 依赖 data
• fetchData 又可能更新 data
• 触发重新执行 effect

结果：

👉 无限循环请求 / 多次重复执行

三、依赖写错的本质问题

👉 React 无法“自动猜测你依赖什么”

因为React 的设计原则是：

side effect must be explicit(清楚明白的，明确的)

四、为什么 React 不帮你自动处理依赖？

核心原因有三个：

1. JavaScript 是动态的

xxxxxxxxxx
const x = props[a ? b : c];

👉 React 无法静态分析真实依赖

2. 闭包问题

effect 捕获的是“某一轮 render 的变量”

3. 性能成本

如果 React 自动追踪： 👉 会变成“全量依赖追踪系统” 👉 性能不可接受

五、真实开发总结

❌ 依赖少会造成：

• stale data
• UI 不更新
• 逻辑错误

❌ 依赖多会造成：

• 重复请求
• 无限循环
• 性能下降

✅ 正确做法：

• 明确写依赖
• 用 ESLint react-hooks/exhaustive-deps
• 必要时用 useRef / useCallback 优化

一句话总结：dependency 写错 = React 逻辑同步失败

Standard Answer (English)

1. Missing dependencies

Leads to stale closure issues:

• Effect uses outdated values
• State inside effect is not updated

2. Extra dependencies

Leads to:

• unnecessary re-execution
• performance issues
• possible infinite loops

3. Why React doesn’t auto-handle deps?

Because:

1. JavaScript is dynamic and hard to statically analyze
2. Effects rely on closures
3. Automatic tracking would be too expensive performance-wise

面试口语版（中文）

如果 useEffect 依赖写少了，就会出现闭包拿到旧值的问题，导致数据不同步。如果写多了，会导致 effect 频繁执行，甚至可能引发无限循环。React 不帮我们自动管理依赖，是因为 JavaScript 是动态的，React 无法准确判断你真正依赖哪些变量，所以必须开发者自己显式声明。

Interview Spoken Answer (English)

If dependencies are missing, we may get stale closure issues where the effect uses outdated values. If we include too many dependencies, the effect may run too often and even cause infinite loops or performance issues. React doesn’t automatically manage dependencies because JavaScript is dynamic and closures make it hard to statically determine what values are truly used, so developers must explicitly declare them.

Q8: useEffect 和 useLayoutEffect 有什么区别？在真实项目中你会怎么选择？

请重点回答这几个点：

1. 执行时机有什么不同？
2. 会不会阻塞浏览器渲染？
3. 什么场景必须用 useLayoutEffect？

1. 执行时机区别

useEffect

• 在 浏览器完成绘制（paint）之后 执行
• 属于 异步执行

👉 不会阻塞页面显示

useLayoutEffect

在 DOM 更新完成（commit phase）后，浏览器绘制之前同步执行

👉 会阻塞浏览器绘制

2. 是否阻塞渲染？

3. 关键本质区别

useEffect：

👉 “先把页面画出来，再处理副作用”

useLayoutEffect：

👉 “先处理完 DOM，再让浏览器画”

4. 为什么 useLayoutEffect 会阻塞？

因为它是：

• 同步执行
• 在 paint 前运行

所以 React 必须等它执行完才能继续绘制

5. 真实项目怎么选？

默认用 useEffect（99%场景）

适合：

• 请求数据
• 订阅事件
• 打 log
• 非 UI 关键逻辑

必须用 useLayoutEffect 的场景

• 测量 DOM 尺寸

  xxxxxxxxxx
  useLayoutEffect(() => {
    const width = ref.current.getBoundingClientRect().width;
  }, []);
  

  👉 防止闪烁

• 避免 UI 抖动（layout shift）

  例如：

  • tooltip 位置计算
  • modal 定位
  • 滚动修正

• 同步 DOM 修改

  比如：

  • 强制 scroll position
  • 立即调整样式

6. 面试关键点总结

👉 useLayoutEffect = “防闪烁工具”

一句话总结

• useEffect：不影响画面，异步执行
• useLayoutEffect：阻塞绘制，同步执行 DOM 计算

Standard Answer (English)

1. Timing difference

useEffect

Runs after the browser paints the screen (async).

useLayoutEffect

Runs after DOM updates but before paint (sync).

2. Rendering impact

3. Core idea

• useEffect → “paint first, then run side effects”
• useLayoutEffect → “run effects before painting”

4. When to use useLayoutEffect

• measuring DOM size
• preventing flicker (layout shift)
• synchronizing layout changes before paint

面试口语版（中文）

useEffect 是在浏览器绘制完成之后执行的，不会阻塞页面渲染。而 useLayoutEffect 是在 DOM 更新完成后、浏览器绘制之前同步执行的，所以它会阻塞渲染。一般情况下用 useEffect，只有在需要读取 DOM 布局或者避免页面闪烁的时候才用 useLayoutEffect。

Interview Spoken Answer (English)

useEffect runs after the browser has painted the screen, so it doesn’t block rendering. useLayoutEffect runs synchronously after DOM updates but before painting, so it blocks the browser from rendering until it finishes. In most cases we use useEffect, and only use useLayoutEffect when we need to measure DOM or prevent visual flickering.

Q9: useContext 的作用是什么？它和“props 层层传递”有什么本质区别？

请结合真实项目回答：

1. 为什么 React 提供 Context？解决什么问题？
2. Context 更新会发生什么（性能角度）？
3. 什么情况下不适合用 Context？

1. useContext 的作用

useContext 用于：跨层级共享数据，避免 props 层层传递（props drilling）

例如：

• 用户信息（user）
• 主题（theme）
• 语言（i18n）
• 登录状态

传统 props 传递问题：

xxxxxxxxxx
App → Page → Layout → Header → Avatar

中间组件只是“转发数据”，但不使用。

Context 方案：

xxxxxxxxxx
const UserContext = createContext();
const user = useContext(UserContext);

👉 直接获取，不需要层层传递

2. Context 更新会发生什么？

所有消费该 Context 的组件都会重新渲染

这是面试重点 ⚠️

Context 本质是：“全局订阅源”。

一旦 value 变化：

• 所有 useContext 的组件都会 rerender

性能问题示例：

xxxxxxxxxx
<UserContext.Provider value={{ name }}>

每次 render 都创建新对象：所有子组件都会更新

3. 为什么 Context 不是状态管理工具？

因为它没有：

• 精细更新控制
• selector 机制
• 局部订阅优化

👉 所以它适合“低频变化数据”

4. 什么情况不适合用 Context？

❌ 高频更新数据

例如：

• input 输入值
• 鼠标位置
• 动画状态
• 实时列表数据

👉 会导致全局 rerender

❌ 大规模状态拆分

Context 会变成“全局 rerender 触发器”

5. 正确使用场景

✅ 适合：

• 登录用户信息
• theme
• language
• 权限信息

❌ 不适合：

• 表单状态
• 局部 UI 状态
• 高频变化数据

一句话总结： Context 用来“共享数据”，但不是“高性能状态管理工具”

Standard Answer (English)

1. Purpose of useContext

useContext is used to avoid prop drilling by sharing data across deeply nested components.

2. What happens when Context updates?

When the context value changes, all components consuming that context re-render.

This is because they subscribe to the context provider.

3. Why not always use Context?

Because it lacks fine-grained control:

• no selector-based updates
• no partial subscription optimization
• can cause unnecessary re-renders

4. When NOT to use it

• frequently changing state (input, animation, mouse tracking)
• large-scale dynamic updates

5. Good use cases

• user authentication
• theme
• language (i18n)
• global configuration

面试口语版（中文）

useContext 的作用是解决 props drilling 问题，可以让组件跨层级直接获取数据，而不需要一层层传递。但它的问题是，一旦 context 的 value 发生变化，所有消费它的组件都会重新渲染，所以它不适合放高频更新的数据，一般用于用户信息、主题这些变化不频繁的全局状态。

Interview Spoken Answer (English)

useContext is used to solve prop drilling by allowing deeply nested components to access shared data directly. However, when the context value changes, all consuming components will re-render. Because of this, it is not suitable for frequently changing state, and is better used for global but stable data like user info, theme, or language settings.

Q10: useReducer 和 useState 有什么区别？在什么情况下你会选择 useReducer 而不是 useState？

请重点回答：

1. 两者在状态管理模型上的区别
2. useReducer 解决了 useState 的什么问题
3. 真实项目中的典型使用场景

1. 核心区别（本质模型）

useState

👉 “状态 = 直接赋值更新”

xxxxxxxxxx
setCount(count + 1);

• 状态更新是“点对点”
• 每次修改是独立的

useReducer

👉 “状态 = action 驱动 + reducer 计算”

xxxxxxxxxx
const [state, dispatch] = useReducer(reducer, initialState);
​
dispatch({ type: 'increment' });

本质区别一句话

• useState：直接改值
• useReducer：通过“规则（reducer）”统一管理状态变化

2. useReducer 解决了 useState 的什么问题？

问题1：状态逻辑分散

xxxxxxxxxx
setA(...)
setB(...)
setC(...)

👉 逻辑散落在组件各处

useReducer 解决：

👉 所有状态变化集中在 reducer

xxxxxxxxxx
function reducer(state, action) {
  switch(action.type) {
    case 'updateA':
    case 'updateB':
  }
}

问题2：复杂状态更新难维护

例如：

• 表单
• 多字段联动
• 多 step 流程

问题3：难以追踪状态变化来源

useState： 👉 “哪里都可以改”

useReducer： 👉 “只能 dispatch”

3. 什么时候用 useReducer？

✅ 适合场景

• 复杂表单

xxxxxxxxxx
formState = {
  name,
  email,
  password
}

• 多状态联动

  • step form
  • wizard
  • 多条件状态

• 状态逻辑复杂

  比如：

  • 增删改查
  • 状态机（state machine）

• 状态变化需要可追踪

  👉 类似 Redux 思维

4. useState 适合什么？

• input value
• toggle
• loading
• modal open/close
• 简单计数器

5. 面试关键总结

👉 useState = “简单状态” 👉 useReducer = “状态逻辑管理”

一句话总结：当状态变化“有规则、有结构、有多个触发方式”，就用 useReducer

Standard Answer (English)

1. Core difference

useState

Direct state updates:

• simple value updates
• no centralized logic

useReducer

Action-driven state management:

• updates go through reducer function
• logic is centralized and structured

2. Problems useReducer solves

• scattered state logic
• hard-to-maintain complex updates
• unclear state transition flow

3. When to use useReducer

• complex forms
• multi-step workflows
• state machines
• multiple related state updates

4. When to use useState

• simple UI state
• independent values
• low complexity logic

面试口语版（中文）

useState 适合简单状态，比如 input 或 toggle，而 useReducer 更适合复杂状态管理，因为它把所有状态更新逻辑集中在 reducer 里，通过 dispatch 来触发变化，这样状态变化更可控、更清晰，也更容易维护，尤其是在表单或者多状态联动的场景下。

Interview Spoken Answer (English)

useState is suitable for simple state like toggles or input values. useReducer is better for complex state management because it centralizes all state update logic inside a reducer function and uses dispatch to trigger changes. This makes state transitions more predictable and easier to maintain, especially in complex forms or multi-step workflows.

Q11: useMemo、useCallback 和 React.memo 三者在性能优化中分别扮演什么角色？它们之间有什么关系？

请重点回答：

1. 三者分别优化的是什么（值 / 函数 / 组件）
2. 为什么只用其中一个通常“不够”
3. 在真实项目中它们如何配合使用

1. 三者分别优化什么？

useMemo

👉 优化 “计算结果（值）”

xxxxxxxxxx
const filteredList = useMemo(() => {
  return list.filter(item => item.active);
}, [list]);

• 避免重复计算

useCallback

👉 优化 “函数引用”

xxxxxxxxxx
const handleClick = useCallback(() => {
  console.log(count);
}, [count]);

• 避免函数重新创建

React.memo

👉 优化 “组件重渲染”

xxxxxxxxxx
const Child = React.memo(function Child(props) {
  return <div>{props.value}</div>;
});

• props 不变 → 不重新渲染组件

2. 它们的关系（重点）

👉 它们是层层配合的

场景：

xxxxxxxxxx
<Child onClick={() => doSomething()} value={data} />

问题：

• inline function → 每次 render 都变
• data 可能是新引用
• Child 会 rerender

正确优化组合：

xxxxxxxxxx
const handleClick = useCallback(() => {}, []);
​
const data = useMemo(() => compute(dataSource), []);
​
<Child onClick={handleClick} value={data} />
const Child = React.memo(...)

3. 为什么只用一个不够？

❌ 只用 React.memo

没用 useCallback → props 仍然变 → memo 失效

❌ 只用 useCallback

Child 没 memo → 还是 rerender

❌ 只用 useMemo

函数还是重新创建 → props 仍变化

👉 结论： 它们必须组合使用才有意义

4. 本质理解（面试加分点）

React rerender 来源有三个：

• state 变化
• props 变化
• context 变化

👉 这三者优化的就是：

5. 什么时候“优化反而变慢”？

• 组件很简单
• 计算成本很低
• memo 判断成本 > rerender 成本

结论：不是所有地方都需要优化

一句话总结：React.memo 控制“组件”，useMemo 控制“值”，useCallback 控制“函数”

Standard Answer (English)

1. What each one optimizes

useMemo: Optimizes computed values.

useCallback: Optimizes function references.

React.memo: Prevents unnecessary component re-renders.

2. Relationship

They work together:

• useMemo → stable values
• useCallback → stable functions
• React.memo → prevents child re-render if props don’t change

3. Why one is not enough

Because:

• memo depends on stable props
• callbacks affect props identity
• values affect prop references

All three are interconnected.

面试口语版（中文）

useMemo 用来缓存计算结果，useCallback 用来缓存函数引用，React.memo 用来防止组件在 props 没变化时重复渲染。它们是配合使用的，如果只用其中一个，往往优化是无效的，比如函数没用 useCallback，React.memo 也会失效。

Interview Spoken Answer (English)

useMemo is used to memoize computed values, useCallback is used to memoize function references, and React.memo prevents unnecessary re-renders of components when props do not change. They are meant to work together; using only one of them often does not provide real performance benefits because the others can still cause re-renders.

Q12: useRef 在解决“闭包陷阱（stale closure）”问题时是怎么用的？

请你结合真实场景说明：

1. 什么是 stale closure（不用太学术）
2. 为什么 useEffect + setInterval 容易出现这个问题
3. useRef 是如何解决它的（核心机制）

1. 什么是 stale closure（闭包旧值问题）

简单理解： 一个函数“记住”了它被定义时的变量值，即使这些变量在后续的组件渲染中已经发生了变化，该函数内部依然在使用那个旧的值。

示例：

xxxxxxxxxx
import React, { useState, useEffect } from 'react';
​
function Counter() {
  const [count, setCount] = useState(0);
​
  useEffect(() => {
    const timer = setInterval(() => {
      // 这里的 count 形成了闭包，它“锁死”在了这个 Effect 第一次执行时的值（即 0）
      console.log(`Current count: ${count}`); 
    }, 1000);
​
    return () => clearInterval(timer);
  }, []); // ⚠️ 注意：依赖数组为空，Effect 只有在挂载时运行一次
​
  return (
    <div>
      <p>Count: {count}</p>
      <button onClick={() => setCount(count + 1)}>增加 Count</button>
    </div>
  );
}
​

为什么会出现 Stale Closure？

①首次渲染：count 为 0。useEffect 运行，创建了一个 setInterval 回调函数。

②闭包形成：这个回调函数捕获了当前渲染周期的 count 变量（其值为 0）。

③点击按钮：你点击了多次按钮，count 在 React 内部已经变成了 1, 2, 3...，组件也重新渲染了。

④陷阱发生：但由于 useEffect 的依赖数组是 []，它不会重新运行，因此 setInterval 里持有的依然是第一次渲染时的函数引用。那个函数闭包里的 count 永远是 0。

2. 为什么 setInterval 很容易出问题？

xxxxxxxxxx
useEffect(() => {
  const id = setInterval(() => {
    console.log(count);
  }, 1000);
}, []);